Quality Control Editor
The Quality Control Editor page is accessible from the main menu under the QA/QC item. While this page falls under the purview of system administrators access can be granted to non-admin users via the User Management page by checking the QA/QC Admin right in the Additional Permissions section.
Be aware that any account granted the QA/QC Admin right will be able to create, edit and/or remove ANY definition as they see fit. It is recommended you only grant this right to responsible folks who have knowledge about what constitutes good QA/QC rather than giving free rein to any and all users.
The layout of the builder is similar to CFE with a list of selectable items on the left and an editing pane for the selected item on the right. In the middle is a splitter which you can use to change the size of either pane.
When you save your changes they take effect immediately. No restart of any service is required.
Defining QA/QC Rules
There are two main groupings when it comes to defining the rules QAQC utilizes to monitor and notify for quality: System-defined and User-Defined. You will notice the rule selection pane consists of two tabs which present the rules respectively.
System Defined QAQC
These rules are created automatically by the system to reflect the basic rule sets applicable to your current configuration. As you modify your sensor suite in CFE and publish your changes SCS will attempt to redefine these rules to accommodate your changes as well.
Since these rules are created and managed by the system itself you cannot tailor them to your needs. However, should one of them prove to be incorrect you can disable them or prevent them from logging so at least they will be ignored.
User Defined QAQC
Building out your ship's set of rules for monitoring the quality of the incoming data feeds starts by clicking the Create New Quality Control Definition button.
Once this button is clicked a new empty definition will appear in the selection pane and you can start defining it on the right in the editing pane. The editing pane consists of two tabs, the first is where you define what triggers the definition and the second tab defines how you want SCS to alert users should the rule be triggered.
Definitions may act on 1 or more sources, so name them appropriately. You will most likely have a set of standard rules for standard data types (e.g. below is a "Range" rule for a heading to ensure it is noted should it report outside a normal compass range) but you may also have advanced rules (for instance comparing all the GYROs to ensure they don't deviate from each other by more than 'x' degrees).
Many of the familiar function types from SCSv4 (DataMon) have transitioned into SCSv5.
Sync: QA/QC attempts to locate a Sync String in every message starting at the position given by String Position
Range: QA/QC verifies that a data field's value falls within the High/Low numbers you provide and trigger if the value falls outside this range.
Delta: QA/QC compares consecutive values for a given data field and verifies that the absolute value of the difference falls within the High/Low numbers you provide. It will trigger if the value falls outside this range.
Timeout: Number of seconds to pass since the previous message before SCS considers a sensor’s data to be "stale" and triggers the alert.
Custom: Users can also define custom equations, similar to the custom equations of Calculated Interfaces in CFE, which allow you to create much more advanced rules based upon your own logic (See also Custom Equations). The primary difference is that the resultant value is Boolean, a logical expression that returns either true or false. Similarly to CFE, users must assign data fields as variables and give them a friendly name to use in an expression. The timeout duration of a timed-out sensor is also available as an input category. See Custom Definitions for more information.
NMEACheck: NMEA Checks evaluate the checksum value of the NMEA message and the correctness of the message start and message label.
Timesource: Comparison against other systems providing official time (NTP, GNSS, etc).
For pre-programmed function, the user must also specify the severity of the rule for each relevant parameter. In the event this definition should trigger (e.g. fall outside the range you specify, etc.) then the issue could be construed as a Warning for your users and dataset or could be an Error. For instance, having a speed that's high or approaching a bad state but is still within reason might be a Warning whereas having a speed that's illogical (like a ship moving along at 50 knots) is most likely an Error.
Simply check the box to specify a severity range and then click the appropriate box in the Value column to set it.
A Warning state is not required before an Error. Some situations are binary and are simply right or wrong. For instance, if a GYRO is between 0 and 360 then things might be fine, but the instant it reads 361 that is an Error.
You can create as many QA/QC definitions as you wish. Generally the more the better as they provide in-situ feedback regarding the state of your sensor feeds. However, you may have rules you don't want to run at any given moment or you may have rules that are 'work in progress' or you may have rules which are triggering off a bad sensor you already know about and are slated to replace soon. Rules in these categories can be disabled by unchecking the Enabled box. Disabled rules will remain in the system but will not be evaluated and will be ignored until they are re-enabled. When a rule's state changes it is logged for future reference. You can disable this as well.
While it is tempting, it is not advisable to disable rules because they are annoying you. A better solution would be to fix the rule (if the logic is wrong) or fix the source of the problem it's alerting you to.
QA/QC Definitions work off sensor data, so depending on which function type you select you will have to enter one or more sources for which the rule will evaluate against. These data sources will appear in the Parameters section of the editor pane. You will be presented with drop down lists to choose what values you want to use for relevant row/columns.
Finally you must supply the logic which defines the rule. These are described by the Inputs section. In the instance of a Range check you would have to supply the High and Low values, if you were defining a Timeout you would supply the number of seconds before timing out and so forth.
If you wish to add any alerts to your definition you may do so on the Alerts tab. Here you can specify ways of notifying people should your definition be triggered. This does not have any impact on whether it is recorded or noted in the QA/QC monitor and is simply an additional (active vs passive) means of notification.
Custom Definitions
The custom logic equation in QA/QC allows for a Warning resultant severity or an Error resultant severity. If the result for the Error expression is false, then the Warning expression is evaluated. If the result for the Warning expression is false, then the resultant severity is Normal. Below is a simple custom equation that uses the result of the derived value of a standard deviation calculation for wind speed value that would be defined in CFE. In this example, if the wind speed is greater than four standard deviations, the severity is Error; if it is greater than three standard deviations, the severity is Warning; otherwise, the severity is Normal.
As with custom equations in CFE, the algebraic expression entered is what would appear on the right-hand side of an equation’s equals sign (=). Given the friendly name variables and the provided functions and constants, the expression should otherwise follow the syntax the C# programming language. The conditional logical operations available are && for AND, and || for OR. For example, one could construct an expression using the friendly names pressure and depth
For custom equations, the user can program the Warning logic, the Error logic, or both. If either the Warning logic or the Error logic is undesired, simply leave blank.